Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log weather periodically via OpenWeatherAPI - proof of concept/WIP #1307

Conversation

CloCkWeRX
Copy link
Collaborator

@CloCkWeRX CloCkWeRX commented Apr 10, 2017

#863
For simplicity, I've just left a default/hardcoded API key in so its easy to play with - that'll be gone by the final version

TODO:

@mention-bot
Copy link

@CloCkWeRX, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Br3nda, @maco and @tygriffin to be potential reviewers.

@CloCkWeRX
Copy link
Collaborator Author

Super annoying, I have no idea how likes_controller has changes on it.

Copy link
Member

@Br3nda Br3nda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea why schema.db changed so much?

@Br3nda
Copy link
Member

Br3nda commented Apr 10, 2017

Btw I have and old fork of grow stuff with moisture , light, temp,and fertiliser readngs per planting (actually per sensor, which is associated with many plantings).

Copy link
Member

@Br3nda Br3nda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A new rake task costs $ on heroku. Will this be part of an existing worker?

# "name":"London",
# "cod":200
# }
class PlantingWeatherLog < ActiveRecord::Base
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be per garden? Or even per location? The basil and the tomatoes are next to each other so have the same weather afaik

Copy link
Collaborator Author

@CloCkWeRX CloCkWeRX Apr 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went for planting so you can answer things like "Why did my leeks grow better last year than this year? Oh, 27 days of 40 degree temperature in a row on last year's planting" more easily

IE its simpler to do SELECT AVG(temp) FROM planting_weather_log WHERE planting_id = ? and only have data recorded for the duration of the planting; than it is to do

SELECT AVG(temp) FROM garden_weather_log JOIN gardens JOIN plantings WHERE garden_weather_log.created_at BETWEEN planting.start and planting.end GROUP BY planting_id
x lots.

Plantings also have a start and end date usually (planting.active); while a Garden is forever; and at least one per user; even if they never do anything with the site.
I suspect we'd run out of the free tier of API usage if we did that for everyone's gardens.

For dealing with plantings in the same garden/location/etc; we can probably cache the API requests at a city/geocoded location level.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about a weather log for a timestamp+location, then a planting links to that? Then the weather for a member's 100+ plantings isn't duplicated.

@CloCkWeRX
Copy link
Collaborator Author

schema.rb changing
That's my local DB having a bunch of different feature branches on it; and me (tiredly) doing a rubocop --auto-correct && git commit -a; sigh.

Prior to merge, I'll go clean it up to be only relevant bits.

@CloCkWeRX
Copy link
Collaborator Author

Will pick this up again in a while

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants